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INTRODUCTION:  A  PROCESS  TO  CONTROL 
SOFTWARE  ARCHITECTURE 

Military  systems  must  be  able  to  change  to 
accommodate  new  mission  needs,  threats,  and 
technology.  At  the  same  time,  military  systems  are 
being  developed  with  budgets  that  are  more  and 
more  limited.  We  need  to  find  ways  to  keep  costs 
down  and  to  maximize  adaptability — for  new 
systems  and  for  extensions  to  existing  systems  that 
must  be  preserved.  A  system’s  software  architecture 
is  a  key  determinant  of  the  system’s  adaptability.  A 
well-conceived  and  well-maintained  architecture 
allows  reusable  components  to  be  included  in  the 
original  development,  custom  components  to  be 
smoothly  integrated  via  standard  interface  protocols, 
and  improved  components  to  be  incorporated  as 
replacements  or  enhancements  are  needed.  To  be 
useful,  the  software  architecture  must  first  be 
articulated  and  include  provisions  for  change; 
second,  it  must  be  controlled  and  maintained 
throughout  the  system’s  life  cycle. 

In  this  paper,  we  define  a  process  that  can  be 
used  ro  ensure  that  system  acquisitions  include 
attention  to  the  software  architecture.  Attention  to 
software  architecture  begins  with  the  very  first 
discussions  of  the  system’s  scope  and  concept,  and 
extends  through  system  maintenance.  The  periods  in 
a  system’s  life  critical  to  establishing  and  retaining  a 
good  architecture  extend  from  formal  notification  to 
industry  of  the  government’s  need  for  the  system, 
through  the  evaluation  of  industry’s  response,  the 
sequence  of  design  reviews  during  the  contractor’s 
design  and  implementation,  and  long-term  mainte¬ 
nance  of  the  operational  system. 

Before  describing  the  process,  we  must  first 
identify  how  to  describe  software  architecture.  In 
general,  the  attributes  of  software  architecture 
include: 

•  software  partitioning 

•  flow  of  data 

•  flow  of  control 

•  timing  and  throughput  relationships 


•  interface  layering  and  protocol  standards 

•  hardware/software  allocation. 

Although  these  attributes  may  overlap  with  concepts 
considered  to  be  system  architecture,  regardless, 
these  attributes  need  to  be  established  before 
software  architecture  can  be  evaluated  or  controlled. 
The  specific  content  of  what  is  controlled  under 
software  architecture  must  be  determined  for  each 
program.  Similarly,  the  level  of  detail  contained  in 
descriptions  of  the  software  architecture  attributes, 
as  well  as  distinctions  between  architecture  and 
design,  must  be  determined  for  each  program. 
Attributes  should  be  considered  architecture  when 
they  express  relationships  that  contribute  to  the 
system’s  long-term  tolerance  to  changes;  they  should 
be  considered  design  when  they  are  implementation- 
specific. 

We  provide  some  background  behind  the 
initiative  to  have  architecture  defined  and  preserved 
in  modem  acquisitions*,  and  we  define  the  term 
software  architecture.  We  also  provide  information 
that  can  be  used  to  structure  the  package  the  govern¬ 
ment  uses  to  solicit  proposals  from  industry  for 
systems  that  strongly  depend  on  computer  software, 
and  we  offer  guidance  for  monitoring  the  execution 
of  a  software  development  contract. 

We  believe  that  following  the  process  described 
here  for  acquiring  software  (see  figure  on  the  next 
page)  will  result  in  systems  that  better  meet  user 
needs  by  encouraging  the  development  of  more 
maintainable,  flexible,  extensible  software  architec¬ 
tures.  The  acquisition  of  software  architectures  will 
be  most  effective  when  there  is  cooperation  between 
the  government  and  industry,  and  attention  applied 
by  both  towards  the  goal  of  building  systems  that 
can  accommodate  change. 
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BACKGROUND:  THE  IMPORTANCE  OF 
ARCHITECTURE  TO  SOFTWARE 
FLEXIBILITY 

One  of  the  prime  benefits  originally  attributed  to 
the  use  of  software  is  its  inherent  flexibility.  Unfor¬ 
tunately,  for  a  variety  of  reasons,  the  potential 
benefits  of  such  flexibility  have  been  lost  in  many 
systems.  In  fact,  users  identify  the  lack  of  flexibility 
and  adaptability  as  two  of  the  major  disadvantages 
of  recent  systems.  Users  have  been  forced  to 
continue  using  outdated  (and  sometimes  improper) 
procedures  solely  because  of  the  expense  required 
(time  as  well  as  money)  to  modify  the  computer 
software.  The  rigidity  of  some  software  has  even 
dictated  that  obsolete  hardware  be  retained  because 


of  the  difficulty  of  moving  the  software  to  newer 
machines. 

If  a  system  is  to  have  a  long,  useful  life,  the 
allocation  of  software  capabilities  to  components 
may  need  to  be  altered.  For  example,  technology 
advances  may  make  available  specialized  hardware 
that  can  substitute  for  particular  software  compo¬ 
nents,  new  software  algorithms  may  replace  hard¬ 
ware  devices,  or  future  mission  capabilities  may  be 
predicted.  Buyers  should  not  only  anticipate  such 
possibilities,  they  should  provide  bidders  with  an 
indication  of  future  needs  via  a  vision  statement. 
Likewise,  bidders  are  encouraged  to  propose 
structured  architectures  with  appropriately  selected 
components  so  that  the  system  can  be  expected  to 
have  a  long  and  stable  life.  Bidders  must  address 
how  one  or  more  proposed  architectures  provide  for 
the  prospect  of  a  long  system  life. 

With  the  anticipated  duration  of  modem 
systems,  it  is  vitally  important  that  systems  be  able 
to  evolve  as  application  needs  change  and  as  users 
come  to  appreciate  the  potential  capabilities  of 
systems.  Although  at  the  outset  of  a  systems 
development  project  the  designers  are  able  to 
describe  desirable  characteristics  and  a  logical 
structure,  by  the  time  the  systems  are  delivered  their 
structures  are  too  often  constrained  and  awkward. 
Instead  of  receiving  well-organized  systems  with 
clean  interfaces,  users  receive  systems  whose 
distribution  of  functions  appears  contrived. 

It  has  been  observed  that  the  original  organized 
structure  becomes  distorted  as  the  detailed  designers 
choose  expedient  solutions  to  challenging  implemen¬ 
tation  problems.  As  these  expediencies  compound, 
the  software  architecture  of  the  delivered  system 
becomes  more  and  more  convoluted.  This  convo¬ 
luted  structure  makes  it  nearly  impossible  for  the 
implemented  or  maintained  to  find  a  logical  point 
for  introducing  needed  functions,  and  leads  either  to 
prohibitively  rising  costs  or  to  ossification  and 
eventual  discard  of  the  system.  Such  an  end  to  well- 
conceived  systems  is  consistently  encountered 
because  modifications,  sometimes  extensive,  are 
inevitably  needed  during  the  course  of  a  system’s 
operational  life. 
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To  obtain  the  benefits  of  flexibility  within  a 
system,  the  software’s  structural  attributes,  which 
are  present  at  the  beginning  of  the  design  thought 
process,  must  be  captured.  These  attributes  are 
typically  called  “architecture,”  although  the  subtle 
distinction  between  architecture  and  design  varies 
among  practitioners.  What  is  important  is  that  a 
management  process  be  established  for  preserving 
the  architecture.  This  process  must  ensure  that: 

•  A  vision  is  established  and  documented  that 
conveys  a  sense  of  direction  for  future 
capability  growth 

•  A  structure  is  defined  for  the  software,  and  is 
stable  before  decisions  crucial  to  the 
implementation  are  fixed 

•  The  structure  and  its  rationale  are  formally 
recorded  for  the  implemented  and  approvers  of 
the  design 

•  The  structure  is  revisited  and  reaffirmed,  or 
modified  in  a  controlled  manner  and  preserved, 
throughout  the  life  cycle. 

For  the  process  proposed  here  to  work  effec¬ 
tively,  the  government  and  contractor  must  designate 
people  to  oversee  the  architecture  and  ensure  the 
system  implementation  preserves  the  architecture’s 
desirable  aspects. 

Cost  Considerations  of  a  Flexible  Architecture 

Cost  is  sometimes  raised  as  a  concern  about 
trying  to  maintain  the  integrity  of  the  architecture 
structure.  Although  a  software  acquisition  policy 
may  emphasize  software  architecture,  there  is  a 
system  architecture  trade-off  to  be  made.  Hardware 
capabilities  and  software  funcuons  may  nee  J  to  be 
included  that  were  not  in  the  initially  specified 
requirements  but  are  necessary  to  accommodate 
changes  predicted  for  the  future.  Offerors  and  buyers 
must  consider  the  long-term  payoff  for  preserving 
software  architecture.  With  the  falling  price  of 
computer  components,  it  is  preferable  in  most 
situations  to  spend  more  money  on  hardware  rather 
than  sacrifice  the  system’s  extensibility  because  of  a 
shortsighted  compromise  of  the  software  architecture 
to  reduce  hardware  costs.  In  fact,  an  architecture  that 


allows  reuse  of  software  components  or  use  of 
commercial  software  products  may  lower  the 
system’s  tc'al  cost.  Appropriate  consideration  of  the 
full  life  cycle  cost  consequences  must  be  included  in 
any  decisions  regarding  the  generation,  preservation, 
or  abandonment  of  a  software  architecture. 


SOFTWARE  ARCHITECTURE  DEFINED 

Software  architecture  refers  to  the  fundamental 
structural  attributes  of  a  software  system. 

Software  architecture  is  a  top-level  definition  of 
a  software  design  that  is  defined  early  in  a  system’s 
life  cycle.  It  is  the  result  of  system  design  activity  to 
synthesize  a  software  system  that  will  support  the 
system’s  functions;  be  in  concert  with  a  synthesized 
hardware  system;  be  responsive  to  imposed  develop¬ 
mental,  environmental,  and  operational  conditions; 
and  be  demonstrably  supportive  of  a  vision  for 
growth  and  change  The  software  architecture 
defines  the  software  components  that  will  provide 
the  required  algorithmic  functions,  their  interfaces, 
and  an  underlying  execution  concept  for  orderly  and 
efficient  accomplishment  of  the  algorithmic  func¬ 
tions.  As  design  progresses,  the  architecture  captures 
more  specific  information,  such  as  a  software  system 
execution  model  that  includes  specific  operating 
system  selections,  specific  interface  and  communica¬ 
tion  protocols,  and  specific  multiprocessing  and 
multiprogramming  paradigms. 

The  distinction  between  software  architecture 
and  software  design  is  not  absolute.  However,  design 
is  considered  more  detailed;  it  is  a  realization  of  the 
architecture  into  a  product  that  fulfills  the  system 
requirements.  The  essential  properties  that  must  be 
described  to  express  a  software  architecture  include: 

•  Partitioning  software  into  components.  These 
should  be  the  major  software  entities  that  will  be 
recognized  and  manipulated  by  the  software 
developers  as  the  natural  partitions  within  the 
software.  In  this  context,  “component”  is  used 
in  a  general  sense  and  does  not  specifically  refer 
to  Computer  Software  Components  (CSCs). 
Components  may  be  determined  by  grouping 
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algorithmic  functions,  objects,  and  reusable 
components  such  as  operating  systems  and 
database  systems,  or  by  any  other  scheme 
appropriate  to  the  proposer’s  development 
methodology. 

•  Row  of  data.  This  should  reveal  the  mecha¬ 
nisms  for  managing  the  flow  of  data  through  the 
components.  It  should  show  the  major  data 
paths  between  and  among  transformation 
processes  as  well  as  to/from  data  storage.  Where 
the  flow  of  data  is  controlled  by  table-driven 
design,  the  table  data  structures  and  their  rules 
for  modifying  data  flow  should  be  described.  It 
should  define  data  structures  and  how  file 
management  and  database  management 
structures  will  be  used. 

•  Flow  of  control.  This  should  reveal  the  mecha¬ 
nisms  for  managing  the  flow  of  control  among 
the  components.  It  should  show  the  major 
execution  sequences,  where  execution 
sequences  may  be  asynchronous  or  parallel,  and 
how  synchronization  is  managed.  Where 
execution  control  uses  data-driven  design,  the 
mechanisms  for  accessing  the  table  and 
managing  execution  should  be  described.  It 
should  also  show  how  anomalous  conditions 
such  as  error  handling  and  exception  conditions 
that  may  dynamically  alter  the  flow  of  execution 
are  managed. 

•  Critical  timing  and  throughput  attributes.  The 
architectural  devices  used  to  manage  critical 
timing  events,  interrupts,  throughput  demands, 
and  data  buffering  should  be  described. 

•  Interconnection  layers,  standards,  and  protocols. 
The  layered  view  should  show  the  grouping  of 
software  components  into  layers  containing 
collections  of  services  whose  interfaces  to  the 
rest  of  the  system  are  defined.  It  should  specify 
the  rules  for  allowable  interconnections  among 
the  layers.  The  use  of  standardized  interface 
protocols  and  bindings  within  and  between 
layers,  such  as  SQL,  GOSIP,  Motif,  OSI,  IEEE 
806.X,  etc.,  should  be  indicated. 

•  Allocation  of  software  to  hardware.  The  mecha¬ 
nism  for  assigning  software  to  specific  hardware 


devices  should  be  defined.  Where  critical  design 
performance  is  determined  by  such  allocation 
(e.g.,  signal  processing  software  might  need  to 
be  executed  on  custom  systolic  array  hardware), 
the  allocation  should  be  defined. 

The  definition  of  what  constitutes  a  “good” 
software  architecture  is  not  provided  here.  Goodness 
must  be  judged  on  a  case-by-case  basis  during 
source  selection  and  each  time  modifications  or 
refinements  to  the  software  architecture  are  proposed 
during  a  system’s  life  cycle.  In  general,  architectures 
are  judged  to  be  good  when  they  satisfy  the  objec¬ 
tives  outlined  in  the  government’s  specification  and 
vision  statement. 


PREPARING  A  REQUEST  FOR  PROPOSAL 

The  government’s  expectations  about  a  new 
system  are  conveyed  to  industry  as  a  Request  for 
Proposal  (RFP),  which  comprises  a  number  of 
documents.  For  software  architecture  information  to 
be  adequately  evoked,  the  RFP  package  must 
include  specific  information  that  traditionally  has  not 
been  included  in  the  RFP.  The  package  must  make 
clear  to  potential  bidders  that  the  government’s 
assessment  of  the  proposal  will  include  assessing  the 
software  architecture. 

System/Segment  Specification 

The  System/Segment  Specification  (SSS) 
provided  with  the  RFP  package  provides  functional 
and  performance  requirements  that  must  be  satisfied 
by  the  contractor.  The  SSS  also  contains  require¬ 
ments,  such  as  interface  standards,  language  con¬ 
straints,  fault  tolerance,  and  security,  that  influence 
architecture  and  must  be  considered  by  the  contrac¬ 
tor  when  the  architecture  is  being  defined. 

The  SSS  should  include  the  requirements 
necessary  for  the  system  to  meet  the  user’s  known 
needs.  These  may  include  architectural  requirements 
when  specific  (testable)  flexibility  and  extensibility 
requirements  are  known.  However,  the  SSS  should 
not  be  developed  so  as  to  dictate  a  particular 
architectural  solution.  Rather,  it  should  emphasize 
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the  need  for  long-lived  viability  of  the  proposed 
architecture.  If  an  acquisition  has  a  requirement  for 
exact  interfacing  with  (or  replacement  for)  an 
existing  system,  then  the  architecture  may  be 
constrained  to  the  extent  that  architectural  properties 
constitute  a  legitimate  requirement,  such  as  conform¬ 
ing  to  standards  or  using  standard  components.  Even 
in  this  case,  though,  the  SSS  should  not  impose 
unnecessary  restrictions  on  the  architecture. 

Vision  Statement 

In  this  new  process  for  acquiring  software 
architecture,  acquisitions  or  developments  should 
include  a  vision  statement  in  the  RFP  package.  The 
capabilities  described  in  the  vision  are  not  prerequi¬ 
sites  for  the  successful  proposal;  however,  architec¬ 
tural  flexibility  sufficient  to  accommodate  those 
capabilities  is  sought  by  the  government.  The  SSS 
contains  known  requirements  the  delivered  system 
must  fulfill;  the  vision  statement  describes  new 
capabilities  the  system  might  need  to  provide  in  the 
future. 

In  the  vision  statement,  the  user  should  provide, 
to  the  extent  possible,  potential  future  changes  in 
threats  and  in  the  role  and  mission  of  the  system. 

The  acquisition  organization  should  integrate  the 
user’s  vision  of  future  changes  with  other  potential 
changes,  including  technology  advances,  and  prepare 
the  vision  statement  Examples  of  what  might  appear 
in  a  vision  statement  include  new  functions  (e.g., 
provide  routing  directives  in  addition  to  tracking 
targets),  anticipated  technological  improvements 
(e.g.,  provide  larger  or  better  displays),  and  radically 
innovative  technology  improvements  (e.g.,  direct 
input  through  voice  recognition).  The  architecture- 
relevant  topics  in  the  SSS  and  the  vision  statement 
together  create  the  basis  for  evaluating  proposals. 

If  there  are  known  requirements  for  flexibility, 
maintainability,  and  future  growth  that  must  be  met 
in  the  delivered  system  and  are  firm  when  the  RFP  is 
issued,  then  they  must  be  a  part  of  the  SSS  (e.g.,  if 
the  system  must  accommodate  growth  and  changes 
in  the  message  catalog),  and  the  software  architec¬ 
ture  must  meet  them.  The  vision  statement  adds 
another  dimension  to  the  SSS  by  helping  the  offeror 


make  trade-offs  in  selecting  an  architecture  that  can 
easily  adapt  to  fulfill  potential  future  requirements  at 
minimum  risk  to  the  government,  the  user,  and  the 
maintainer. 

A  vision  statement  is  important  to  the  architec¬ 
ture  process  because  major  system  benefits  may 
emerge  if  the  chosen  structure  is  capable  of  handling 
different  demands.  With  a  robust  and  flexible 
underlying  structure,  a  system  can  absorb  tasks 
different  from  those  identified  to  meet  the  initial 
deployment. 

The  vision  statement  requires  thinking  beyond 
the  immediate  objectives  of  the  users  in  acquiring  a 
new  system.  It  should  be  linked  to  the  user’s  long- 
range  planning  and  speculation  (10  to  20  years),  or 
to  potential  alternative  users,  and  should  not  be 
restricted  by  predefined  allocations  of  functions  to 
organizations,  systems,  or  persons. 

Statement  of  Work 

The  Statement  of  Work  (SOW)  must  reinforce 
the  importance  of  the  architecture  in  the  acquisition 
by  identifying  tasks  related  to  documenting  the 
architecture,  keeping  the  documentation  relevant  as 
the  design  progresses,  and  validating  that  the  archi¬ 
tecture  is  used  in  the  actual  software  design  and 
implementation  and  that  it  allows  satisfaction  of 
system  requirements. 

The  System/Segment  Design  Document 
(S/SDD)  is  the  vehicle  for  expressing  and  control¬ 
ling  the  architecture.  Consequently,  a  specific  task 
must  be  included  in  the  SOW  to  ensure  that  the 
S/SDD  is  produced,  updated,  and  maintained  under 
configuration  control  by  the  contractor. 

The  Software  Development  Plan  (SDP)  is  the 
vehicle  for  defining  the  software  development 
process  the  contractor  expects  to  use.  The  SDP  must 
include  a  description  of  the  processes  and  the  tools 
or  software  engineering  environment  the  contractor 
will  use  to  ensure  the  architecture  is  preserved  by  the 
software  implementation.  Consequently,  a  specific 
task  to  develop  and  maintain  the  SDP  must  be 
included  in  the  SOW. 
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Although  this  process  is  devoted  to  preserving 
architecture,  it  is  not  devoted  to  preventing  its 
refinement  or  modification.  Consequently,  engineer¬ 
ing  analysis  tasks  to  evaluate,  refine,  or  demonstrate 
the  validity  of  the  software  architecture  must  be 
included  in  the  SOW.  Results  of  these  analyses 
should  be  discussed  within  design  reviews  (e.g.,  at 
the  software  walkthrough)  and  at  presentations  to  the 
government.  These  engineering  analysis  tasks  should 
reveal  how  the  architecture  will  behave  in  the  pro¬ 
posed  application,  and  how  it  can  be  generated, 
modeled,  or  prototyped  with  the  contractor’s 
proposed  software  development  process  and 
environment.  These  tasks  should  commence  prior  to 
the  System  Requirements  Review  (SRR).  Because  of 
the  need  to  perform  these  studies,  the  schedule  for 
the  contract  must  allow  time  before  the  SRR.  The 
results  of  the  analyses  must  be  presented  to  the 
government  at  the  SRR,  and  again  prior  to  the  SDR, 
as  drafts  of  the  architecture  portion  of  the  S/SDD. 
Both  the  architecture  and  the  analyses  that  provide 
the  rationale  should  be  documented  in  the  S/SDD 
and  used  to  reach  an  agreement  between  the  devel¬ 
oper  and  the  government  on  the  architecture.  At 
SDR,  the  architecture  portion  of  the  S/SDD  should 
be  placed  under  configuration  control  A  task  must 
be  defined  to  conduct  at  least  one  Technical  Inter¬ 
change  Meeting  (TIM)  for  the  contractor  and  the 
government  to  review  and  agree  on  the  architecture 
between  SRR  and  SDR. 

Additional  engineering  tasks  should  be  included 
in  the  SOW  for  validation  of  the  architecture  itself, 
and  preservation  of  the  architecture  throughout  the 
implementation.  At  a  minimum,  updates  to  the 
S/SDD  should  be  provided  at  each  formal  design 
review  (after  the  SDR,  PDR,  and  CDR),  at  any  time 
an  architectural  change  is  proposed,  and  at  Test 
Readiness  Reviews  (TRRs). 

Most  software  architectures  involve  a  complex 
structure  that  is  difficult  to  understand  and  therefore 
difficult  to  predict.  Early  in  the  formulation  of  the 
software  architecture,  a  model  or  prototype  is 
needed;  this  should  be  an  executable  model  that 
could  be  simulated  to  yield  insights  into  the  software 


component  interface  relationships,  data  flow, 
execution  flow,  and  timing  and  sizing  performance 
of  the  ultimate  system.  Where  complexity  of  the 
ultimate  system  warrants  (to  be  decided  casc-by- 
case),  a  specific  task  to  develop,  document,  and  use 
such  a  prototypc/model  should  be  included  in  the 
SOW.  The  prototype/modcl  will  validate  that  the 
architecture  and  the  implementation  coincide  and 
that  the  architecture  can  meet  system  and  software 
requirements.  The  prototype/modcl  is  not  required  to 
be  an  extract  of  the  final  version  of  the  system, 
although  it  could  be;  rather,  it  is  prepared  to  allow 
meaningful  examination  of  the  architecture.  Results 
of  analysis  of  the  prototype/modcl  should  be  deliv¬ 
ered  to  the  government  at  each  design  review.  In 
some  cases,  the  prototype/modcl  may  also  be  a 
deliverable  for  use  during  the  support  phase  of  the 
system. 

Within  the  context  of  any  implementation,  the 
risk  of  failing  to  meet  some  of  the  requirements  must 
be  carefully  managed.  To  ensure  that  architectural 
features  are  not  needlessly  abandoned  when  attempt¬ 
ing  to  resolve  other  problems,  the  contractor  should 
be  required  to  analyze  the  proposed  system  for 
features  likely  to  pose  implementation  difficulties  or 
increased  costs.  Any  requirement,  capability,  feature, 
or  option  that,  during  the  course  of  the  contract,  is 
discovered  to  fall  into  the  realm  of  a  potential  risk  to 
preserving  the  architecture  and  its  attributes  must  be 
identified  to  the  government  and  a  risk  management 
action  proposed. 

A  task  must  be  defined  to  conduct  trade-off 
studies  whenever  a  change  to  the  architecture  is 
contemplated.  The  trade-off  studies  should  involve 
simulation  modeling  or  demonstration-based  results 
that  provide  a  quantifiable  impact  to  the  architecture 
attributes.  The  results  of  such  trade-off  rtudies  must 
be  presented  to  the  government,  which  must  concur 
before  any  efforts  are  initiated  that  implement  the 
changes.  Government  concurrence  should  be  man¬ 
aged  according  to  the  procedures  for  managing  the 
S/SDD  configuration. 
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Attachment  I  contains  sample  wording  that 
should  be  in  the  SOW.  However,  the  exact  definition 
of  the  tasks  to  be  performed  must  agree  with  the 
goals  of  the  system  under  development. 

Contract  Data  Requirements  List  (CDRL) 

System/Segment  Design  Document.  The 
S/SDD  is  the  vehicle  for  defining  the  design  of  a 
system/segment  and  its  operational  and  support 
environments.  Under  this  new  process  for  acquiring 
software  architecture,  the  architectural  portions  of 
the  S/SDD  will  be  expanded.  Further,  architecture 
information  will  be  requested  from  the  contractor  at 
the  time  of  the  proposal,  at  SRR,  and  before  SDR. 
The  proposal  submittal  may  be  in  the  form  of  a  draft 
of  the  architecture  material  from  the  S/SDD  or  it 
may  be  separately  formatted.  In  either  case  the 
information  necessary  to  understand  and  evaluate  the 
software  architecture  must  be  presented. 

In  accordance  with  DI-CMAN-80534  (S/SDD 
DID)  and  Attachment  II  of  this  paper,  a  description 
of  the  architecture  should  be  provided  with  the 
proposal,  a  preliminary  description  should  be 
provided  at  SRR,  and  an  approved  architecture 
description  should  be  provided  before  SDR. 

Obviously,  the  early  submissions  will  have  less 
detail  defined  than  the  later  ones.  For  example, 
specific  choices  for  software  decomposition  are  not 
expected  in  the  proposal.  Only  the  components  that 
represent  significant  software  capabilities  should  be 
identified  as  software  architecture  components  (e.g., 
operating  system,  database  management  system, 
signal  processing  system,  or  other  breakdown  of 
components  consistent  with  the  developer’s  pro¬ 
posed  methodology,  such  as  functional  decomposi¬ 
tion  or  object-oriented  design).  The  contractor  must 
also  be  required  to  submit  revisions  to  the  S/SDD 
whenever  an  architecture  modification  has  been 
approved  and  the  architectural  information  has 
become  outdated.  In  general,  the  software  architec¬ 
ture  information  should  be  contained  in  section  3.4 
of  the  S/SDD. 

Many  diagrammatic  or  textual  representations 
are  possible  to  emphasize  software  attributes  such  as 


data  flow,  execution  flow,  layering,  or  interface 
protocols.  The  specifics  of  the  notation  and  format  of 
the  information  are  not  as  important  as  recording  all 
the  architectural  information;  for  that  reason,  one  or 
more  contractor-preferred  representations  may  be 
selected  to  complement  one  another  when  assem¬ 
bling  an  architecture  description.  Regardless  of  the 
forms  used,  to  be  acceptable  the  architecture 
representation  must  cover  the  essential  properties 
listed  in  our  definition  of  software  architecture. 

In  addition  to  the  architecture  description,  the 
S/SDD  must  be  supplemented  with  explanatory 
material  for  the  architecture.  The  contractor  must 
include  the  following  rationales  for: 

•  Structure  of  software:  Explain  why  the  partition 
of  software  components  was  selected,  empha¬ 
sizing  why  it  offers  tolerance  for  changes  in 
later  stages  of  the  system’s  life  cycle.  Similarly, 
explain  why  architectural  features  such  as  table- 
driven  design  were  selected  and  what  attributes 
of  tolerance  for  change,  e.g.,  flexibility  and 
extensibility,  are  provided  by  the  chosen 
software  structure.  Mechanisms  for  managing 
the  flow  of  data  and  the  flow  of  execution 
should  also  be  described,  with  the  rationale 
behind  how  they  were  selected. 

•  Rules  for  interaction  of  system  components: 
Explain  why  particular  standards  or  de  facto 
standards  (e.g..  Motif,  Windows,  POSIX 
GOSIP,  Hewlett  Packard  New  Wave  Object 
Management  Facility)  are  being  adopted. 

Provide  the  rationale  for  how  an  architecture 
model  or  profile  was  selected  and  how  inter¬ 
connection  rules  or  layered  protocols  will  be 
enforced  in  the  architecture. 

•  Structure  of  the  hardware  and  software:  Provide 
the  rationale  for  the  choices  made  to  aggregate 
software  components  on  processors  or  to 
distribute  them  on  separate  processors. 

In  addition  to  discussing  how  the  architecture 
relates  to  the  needs  of  the  current  system,  the  S/SDD 
should  address  how  the  architecture  will  handle  new 
capabilities  and  features  as  noted  in  the  vision 
statement.  The  architecture  description  should 
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include  provisions  for  exploiting  migration  paths 
associated  with  improved  versions  of  nondevelop- 
mental  item  (NDI)  products,  and  it  should  describe 
the  limitations  or  capabilities  to  migrate  to  improved 
custom  or  NDI  software.  It  should  also  explain  what 
aspects  of  the  software  are  substantially  enhanced  by 
the  proposed  architecture,  for  example: 

•  Software  testability 

•  Software  maintainability  (e.g.,  isolating  and 

correcting  software  malfunctions) 

•  Software  extensibility 

Attachment  II  contains  a  candidate  rewording  of 
Data  Item  Description  (DID)  DI-CMAN-80534  to 
direct  the  contractor’s  preparation  of  the  S/SDD. 
Caution:  when  preparing  the  description  of  the 
architecture,  the  distinction  between  design  and 
architecture  needs  to  be  considered.  Since  the 
architecture  will  be  placed  under  configuration 
control  relatively  early  in  the  contract  life  cycle, 
implementation  detail  information  is  best  left  out 
The  mechanisms,  rules,  standards,  and  generic 
structural  properties  should  be  included.  Specific, 
low  level,  component-unique  information  that  is  not 
part  of  the  main  structure  of  the  system  should  not 
be  captured.  The  distinction  between  what  is  design 
detail  and  what  is  structural  attribute  needs  careful 
consideration  by  both  the  government  and  the 
contractor.  Consequently,  the  words  used  to  tailor  a 
DID  for  a  specific  contract  should  be  carefully 
considered. 

Software  Development  Plan.  The  software 
architecture  implementation  is  carried  out  by  the 
creation  of  many  software  components,  modules, 
and  routines.  The  creation  steps  must  be  guided  by  a 
process,  defined  in  the  SDP,  that  is  fully  cognizant 
of  the  importance  of  the  software  architecture. 
Therefore,  not  only  is  an  SDP  required  from  the 
contractor  at  the  beginning  of  the  contract,  it  must  be 
resubmitted  whenever  changes  are  made  to  the 
development  process.  The  SDP  must  describe  the 
development  environment  and  any  tools  used  to 
ensure  and/or  verify  the  preservation  of  architectural 
features  during  development.  The  degree  to  which 
tools  can  be  used  to  enforce  architectural  decisions 


should  be  highlighted.  Whether  or  not  automated 
tools  are  used,  the  SDP  must  explain  the  procedures 
by  which  architectural  constraints  are  enforced 
throughout  the  design,  coding,  deployment,  and 
maintenance  phases  of  the  system. 

Information  to  be  included  in  the  SDP  includes: 

•  The  extent  to  which  software  components  are 
NDIs  or  reused,  and  guidelines  for  determining 
the  suitability  of  reused  or  NDI  products 

•  The  process  (sequence  of  activities)  and  tools 
that  will  be  used  to  manage  the  software 
architecture,  including: 

-  Generating  software  in  accordance  with  the 
rules  of  the  architecture 

-  Documenting  and  controlling  the  architecture 
and  changes  to  it 

-  Verifying  that  the  architecture  will  meet  its 
functional  requirements  and  its  requirements 
for  adaptability,  extensibility,  etc. 

-  Predicting  that  the  system  will  meet  its 
performance  (timing)  requirements 

-  Controlling  conformance  of  the  software 
design  and  software  implementation  with  the 
architecture 

-  Determining  how  and  when  the  architectural 
model  or  prototype  will  be  executed 

-  Creating  an  organizational  structure  to 
support  architectural  development,  preserva¬ 
tion,  and  verification 

Attachment  III  contains  a  candidate  rewording 
of  DID  DI-MCCR-80030A  to  direct  the  contractor’s 
preparation  of  the  SDP. 

Other  Documents.  There  may  be  other  docu¬ 
ments  (e.g.,  model/prototype  description,  timing  and 
sizing  reports)  that  are  influenced  by  architecture. 

For  each  one,  the  DID  should  be  amended  to  express 
the  need  for  preserving  software  architecture. 
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Instructions  for  Proposal  Preparation 

The  Instructions  for  Proposal  Preparation  (IFPP) 
must  remind  bidders  about  the  presence  of  the 
software  architecture  policy  and  the  government’s 
emphasis  on  software  architecture  definition, 
evaluation,  and  preservation.  The  IFPP  should 
reiterate  the  relationship  between  the  specification 
and  the  vision  statement,  the  parameters  and 
attributes  to  be  included  in  the  software  architecture 
definition,  and  the  differences  intended  between 
architecture  and  design.  It  must  provide  some  form 
of  completeness  criteria  that  will  enable  contractors 
to  know  how  much  of  the  vision  statement  character¬ 
istics  need  to  be  discussed  in  a  proposal.  It  must  also 
provide  for  enumerated  vision  attributes  so  proposals 
that  offer  solutions  covering  more  of  the  vision  can 
be  distinguished  from  those  covering  less. 

Bidders  must  be  informed  of  the  need  to  provide 
a  description  of  the  software  architecture.  This  will 
be  a  tailored  subset  of  the  information  contained  in 
the  S/SDD.  The  S/SDD  material  should  be  of 
sufficient  depth  for  the  relationship  between  pro¬ 
posed  architectures  and  the  specification  and  vision 
attributes  to  be  understood  by  the  buyers.  This 
architecture-relevant  information  should  have  a  page 
limitation  (e.g.,  50  pages,  including  cover,  index, 
and  supporting  text).  The  bidder  must  adequately 
describe  the  architectural  approach  to  be  used  and 
must  show  how  a  proposed  architecture  will  support 
the  system  requirements  by  including  a  rationale  for 
the  major  architectural  properties  the  offeror 
proposes.  Further  elaboration  on  the  proposed 
architecture  and  its  rationale  may  include  descriptive 
examples  of  previous  systems  that  used  a  proposed 
architecture,  results  of  demonstrations  from  previous 
contracts,  or  results  of  simulations  and  models 
available  for  a  proposed  architecture. 

The  IFPP  must  also  inform  bidders  of  the  need 
to  submit  a  description  of  the  software  development 
processes  and  the  contractor’s  plan  for  developing 
software.  This  material  should  define  the  processes 
and  tools  used  to  support  creating  and  preserving  the 
software  architecture.  The  technical  proposal  should 
provide  the  rationale  behind  why  and  how  those 
software  development  processes  and  tools  ensure 


preservation  of  the  architecture.  Where  appropriate, 
examples  from  past  experience  should  be  cited. 

A  presentation  of  the  techniques  used  in  a 
previous  project  should  be  encouraged  to  lend 
credibility  to  a  bidder’s  representations  about  the 
approach  to  emphasizing  architecture  that  is  pro¬ 
posed.  An  ideal  way  of  combining  past  experience 
and  the  current  effort  would  be  to  have  the  bidder 
demonstrate  the  planned  system  architecture  and 
tools  through  execution  of  a  high-level  model  of  a 
proposed  architecture  during  source  selection.  On  a 
case-by-case  basis,  the  acquisition  organization 
should  determine  whether  or  not  it  is  appropriate  to 
expect  or  require  proposers  to  be  prepared  to  include 
a  demonstration  as  part  of  source  selection. 

The  bidders  should  be  encouraged  to  show  how 
their  model  reveals  whether  an  architecture  supports 
the  specification  and  vision.  For  example,  the  model 
could  show  the  ability  to  port  software  components 
to  multiple  hardware  platforms,  to  modify  compo¬ 
nents  via  the  use  of  computer-aided  software 
engineering  (CASE)  tools,  or  to  replace  one  com¬ 
mercial  off-the-shelf  (COTS)  product  with  another. 

Because  the  ultimate  success  of  the  architectural 
approach  to  the  system  acquisition  will  be  deter¬ 
mined  by  the  designers  and  implemented,  the  role  of 
the  technical  leaders  of  the  design  team  is  of  much 
interest  to  the  government.  The  bidders  are  encour¬ 
aged  to  describe  whether  a  single  architect  or 
architect  team  will  be  appointed,  the  scope  of  this 
person’s  or  team’s  authority,  and  how  the  architect 
or  team  is  expected  to  interact  with  the  rest  of  the 
project  management  team.  Examples  of  previous 
projects  that  used  the  proposed  management 
structure  would  validate  the  likely  success  of  the 
approach. 

Attachment  IV  contains  sample  wording  that 
can  be  used  in  the  IFPP. 

Evaluation  Criteria 

So  that  bidders  will  understand  the  importance 
attached  to  the  architectural  structure  of  a  proposed 
system.  Section  M  of  the  solicitation  package  must 
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indicate  that  the  proposed  architecture,  its  develop¬ 
ment  process,  and  its  maintenance  provisions  will  be 
evaluated.  Further,  it  should  state  that  failure  to 
provide  an  adequate  response  to  the  architectural 
aspects  of  the  proposed  system  will  be  deemed  to 
indicate  non-compliance  with  the  basic  solicitation. 
The  actual  factors  and  standards  that  the  government 
will  use  in  evaluating  the  proposals  will  be  based  on 
the  statements  in  Section  M,  but  will  not  be  provided 
to  the  bidders.  The  evaluation  criteria  included  in 
Section  M  should  be  based  on  a  need  to  assess: 

•  How  the  proposed  approach  and  architecture 
meet  system  requirements 

.  To  what  extent  the  architecture  can  meet  the 
potential  long-term  needs  of  the  system 
described  in  the  vision  statement 

•  To  what  extent  the  proposer’s  software 
development  approach  assures  the  preservation 
of  the  software  architecture 

Although  these  criteria  are  generic  here,  they 
must  be  made  more  explicit  for  the  particular  system 
being  acquired.  The  evaluation  criteria  should  be 
derived  from  the  types  of  tasks  or  capabilities  the 
new  system  may  need  to  accommodate,  and  they 
should  allow  buyers  to  evaluate  whether  or  not 
proposed  architectures  have  a  flexible  underlying 
structure  that  will  accommodate  tasks  different  from 
those  identified  by  the  initial  specification. 


ACTIVITIES  AFTER  CONTRACT  AWARD 

After  the  system  implementation  is  under  way, 
the  government  and  the  contractor  must  jointly 
monitor  the  effort  to  ensure  that  the  architectural 
base  for  the  system  is  maintained.  The  SOW  defines 
the  appropriate  tasks  and,  for  the  most  part,  the 
contract  defines  the  activities  after  contract  award. 
However,  cooperation  is  considered  essential  both  in 
selecting  the  architecture  to  be  used  and  in  preserv¬ 
ing  it.  Therefore,  all  parties  to  the  contract  should  be 
encouraged  to  establish  open  communications  and 
candid  evaluation  of  the  degree  of  success  being 


achieved  with  respect  to  defining  a  sensible  architec¬ 
ture  and  preserving  it  TIMs  can  facilitate  communi¬ 
cation  prior  to  formal  reviews. 

Demonstration/Validation  Effort 

Engineering  analyses  should  allow  the  contrac¬ 
tor  and  government  to  identify  and  quantify  the 
parameters  that  relate  to  imposing  the  chosen 
architecture  on  the  system.  They  should  be  con¬ 
ducted  from  the  outset  of  the  contract  to  refine  the 
architecture  requirements  and  prepare  the  contractor 
and  the  government  for  architecture  discussions  at 
SRR  and  prior  to  SDR.  They  should  also  be  con¬ 
ducted  any  time  architectural  modifications  are 
proposed. 

Modeling  Efforts 

A  realistic  (but  economical)  modeling  effort 
should  be  part  of  any  complex  project  so  that 
probable  performance  can  be  predicted.  Without 
appropriate  modeling,  the  true  consequences  of 
preserving  the  architecture  in  the  face  of  possible 
design  deviations  may  not  be  understood.  These 
modeling  efforts  should  include  the  architecture 
aspects  of  the  system. 

Design  Reviews 

As  a  part  of  each  design  review  during  develop¬ 
ment,  the  integrity  of  the  architecture  must  be 
explicitly  reviewed.  Any  proposed  deviations  from 
the  agreed  architecture  must  be  explained.  Execution 
threads  must  be  presented  as  a  means  of  showing 
that  the  architecture  supports  the  intended  functions 
of  the  system. 

Documentation  and  Configuration  Control 

Between  contract  award  and  SRR,  the  contrac¬ 
tor  and  the  government  will  study  the  proposed 
architecture.  Based  on  the  results  of  engineering 
analyses  done  during  this  time,  the  architecture 
requirements  will  become  stable.  Between  SRR  and 
SDR,  the  contractor  will  prepare  the  formal  S/SDD 
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for  review  and  comment  by  SDR.  Upon  submittal  of 
the  S/SDD,  reflecting  government  comments,  the 
architecture  will  be  placed  under  configuration 
control.  Thereafter,  modifications  may  be  made  to 
the  architecture  but  only  after  trade-off  studies  have 
shown  the  necessity  for  change,  and  the  government 
and  the  contractor  agree  to  the  change.  The  S/SDD 
should  be  updated  to  reflect  the  approved  changes. 
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ATTACHMENT  I  —  STATEMENT  OF  WORK 

The  following  material  is  provided  for  place¬ 
ment  in  the  SOW  to  define  tasks  associated  with 
preserving  the  software  architecture.  These  para¬ 
graphs  are  general  in  nature  and  must  be  tailored  to 
include  specific  references  to  the  CDRL.  The 
specific  tasks  chosen  and  the  degree  of  tailoring 
must  also  match  the  needs  of  each  program.  In 
particular,  the  scope  and  scheduled  completion  of 
the  tasks  must  be  integrated  into  the  overall  plan  for 
the  program.  The  software  architecture  tasks  are 
intended  to  supplement  those  tasks  that  would  be 
part  of  an  acquisition  effort  and  thus  already 
specified  in  the  SOW ;  it  may  be  convenient  to  merge 
this  material  into  the  descriptions  of  other  tasks. 


X.X.X  System  Engineering  —  General 

When  performing  all  system  engineering  tasks, 
the  contractor  shall  ensure  that  the  software  architec¬ 
tural  attributes  are  considered.  All  trade  studies, 
design  decisions,  and  implementation  actions  that 
impact  *he  software  architecture  will  evaluate 
whether  or  not  the  system’s  tolerance  for  change  is 
affected.  In  the  event  that  it  is  affected,  the  contrac¬ 
tor  shall  include  the  analysis  that  justifies  modifica¬ 
tions  to  the  software  architecture  in  terms  of  life 
cycle  cost  of  the  system. 

xjcjc  System  Engineering  —  Analysis 

Before  the  SRR,  the  contractor  shall  analyze  the 
SSS  and  vision  statement  and  identify  requirements 
that  are  judged  to  be  architectural  drivers.  The 
contractor  shall  host  a  TIM,  with  government  and 
support  contractor  participation,  to  review  the 
software  architecture.  The  purpose  of  the  TIM  will 
be  to  review  the  requirements  from  the  SSS  being 
satisfied  by  the  architecture  proposed,  to  assess  the 
ability  of  the  proposed  architecture  to  satisfy  the 
vision  statement,  and  to  coordinate  revisions  of  the 
architecture  requirements  such  that  a  clear  under¬ 
standing  of  the  software  architecture  and  the  criteria 
or  constraints  involved  in  its  definition  is  estab¬ 
lished.  The  architecture  shall  be  described  in  an 


update  of  the  architecture  portion  of  the  S/SDD  and 
shall  be  provided  to  the  government  at  the  SRR.  A 
formal  submission  of  the  architecture  description  in 
the  S/SDD  shall  be  submitted  and  placed  under 
configuration  control  at  SDR.  [DI-CMAN-80534] 

An  explanation  of  the  architecture  of  the  system 
shall  be  included  as  primary  presentations  at  the 
SRR,  the  SDR,  all  software  and  hardware  design 
reviews  (SRR,  PDR,  and  CDR),  and  the  TRR. 
Associated  with  software .  rchitecture  descriptions, 
the  design  process  standards  and  trade-off  heuristics 
that  were  used  as  criteria  or  constraints  by  the 
contractor,  or  by  the  contractor  and  the  government, 
for  selecting  the  architecture  shall  be  expressed  in  an 
Architecture  Analysis  Report  This  report  shall 
contain  the  essential  information  for  later  reviewers 
to  understand  why  the  architecture  choices  were 
made  that  led  to  the  defined  architecture.  The  intent 
is  for  later  reviewers  to  be  able  to  identify  architec¬ 
tural  features  that  are  tied  to  design  assumptions  or 
constraints.  In  the  event  those  assumptions  are 
refined  or  the  constraints  are  lifted,  preservation  of 
those  architecture  features  may  be  reexamined.  Also 
included  in  the  report  shall  be  a  description  of  the 
procedures,  tools,  and  training  by  which  the  govern¬ 
ment  can  maintain  the  architecture  for  the  remainder 
of  the  planned  system  life  after  completion  of  the 
contractor  efforts.  This  report  shall  be  delivered  at 
SRR,  at  SDR,  and  updated  at  any  subsequent  review 
whenever  modifications  to  the  software  architecture 
are  requested.  [DI-MISC-xxxxx] 

x.xa  Software  Engineering 

xxx  Software  Engineering  —  General 

The  contractor  shall  manage,  design,  develop, 
document,  control,  and  qualify  performance  of  the 
computer  software  to  satisfy  the  performance, 
functional,  and  quality  requirements  of  the  SSS.  In 
addition,  to  the  extent  technology  allows,  the 
contractor  shall  provide  an  architectural  framework 
for  the  software  that  accommodates  the  flexibility 
and  extensibility  implied  by  the  vision  statement 
“The  extent  technology  allows”  will  be  determined 
via  TIMs  where  provisions  for  open  system  design. 
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software  reuse,  incorporation  of  layered  architecture 
reference  models,  and  interface  standards  are 
compared  against  the  goals  of  the  program  and  the 
state  of  available  commercial  products,  or  the  state 
of  contractor-developed  architectural  products.  The 
software  architecture  definition  shall  be  governed  by 
the  long  term  cost-effectiveness  goals  to  have  the 
system  under  development  be  tolerant  to  change. 
Decisions  vis  a  vis  architecture  selection  or  modifi¬ 
cation  shall  be  made  on  the  basis  of  requirements 
defined  in  the  SSS,  the  vision  statement,  and  this 
goal  within  the  scope  of  the  contract. 

xxx  Software  Engineering  —  Architecture 
Change  Analysis 

At  each  milestone  after  the  SRR  (i.e.  SDR, 

PDR,  CDR,  and  TRR),  the  contractor  shall  identify 
any  new  enhancements  or  changes  to  the  architecture 
that  affect  the  long  term  tolerance  for  change  in 
requirements,  and  provide  reasons  for  the  differ¬ 
ences.  Before  these  changes  are  presented  at  the  next 
review,  the  contractor  shall  identify  the  changes  at  a 
TIM  convened  20  days  prior  to  the  review.  The 
contractor  shall  update  the  S/SDD  to  reflect  the 
changes  as  agreed  within  30  days  after  the  review.  If 
any  changes  affect  portions  of  the  architecture 
already  under  government  configuration  control,  the 
contractor  shall  be  required  to  generate  an  adminis¬ 
trative  engineering  change  proposal  (ECP)  describ¬ 
ing  the  changes  and  their  rationales.  [DI-MISC- 
xxxx] 

xxx  Software  Engineering  —  Architectural 
Model  or  Executable  Prototype 

The  contractor  shall  prepare  an  executable 
prototype,  model,  or  initial  version  of  the  software 
architecture  framework.  This  model  shall  demon¬ 
strate  the  flexibility,  extensibility,  and  growth 
provisions  anticipated  for  the  selected  architecture.  It 
shall  allow  testing  of  the  timing  and  throughput 
relationships,  the  interfaces  to  products  using 
standard  protocols,  and  the  fundamental  data  flow 
and  control  flow  sequencing,  and  it  shall  demon¬ 
strate  the  anomalous  condition  or  error  handling 
mechanisms  to  be  used  in  the  system.  The  contractor 


shall  present  the  results  of  architecture  modeling  or 
prototype  developments  and  demonstrations  at  the 
SDR,  and  the  results  and  the  model  shall  be  updated 
at  the  PDR  and  CDR.  The  contractor  shall  submit  an 
agenda  for  each  demonstration  and  shall  deliver  a 
report  after  each  demonstration  to  record  any  action 
items  and  decisions.  [DI-MISC-xxxx] 

xxx  Software  Engineering  —  Database  Design 

In  the  process  of  designing  the  logical  and 
physical  structure  of  the  database,  the  contractor 
shall  consider  the  effects  upon  the  database  of  the 
selected  architecture  (and  vice  versa)  and  shall 
ensure  that  the  database  design  is  consistent  with  the 
architecture.  The  design  of  the  database  shall  be 
presented  as  part  of  each  design  review  at  a  level  of 
detail  determined  by  the  maturity  of  the  design  effort 
at  that  time.  The  contractor  shall  deliver  to  the 
government  a  Database  Design  Document  (DID- 
MlSC-xxxx).  A  preliminary  version  of  this  docu¬ 
ment  shall  be  delivered  at  the  (first)  PDR  and  a  final 
version  of  this  document  shall  be  delivered  at  the 
(first)  CDR. 

At  the  SDR,  the  contractor  shall  describe  the 
approach  for  implementing  the  database.  The 
contractor  shall  identify  and  justify  the  need  for  any 
file  management  or  database  management  software. 
The  contractor  shall  discuss  the  partitioning  of  the 
database  and  shall  identify  benefits  and  drawbacks 
due  to  the  planned  database  structure.  Included  shall 
be  a  description  of  the  procedures,  tools,  and  training 
by  which  the  government  can  maintain  the  database 
consistent  with  the  architecture  for  the  remainder  of 
the  planned  system  life  after  completion  of  the 
contractor  efforts. 

x.xjt  Software  Engineering  —  User  Interface 
Design 

The  contractor  shall  develop  the  user-system 
interface  (USI)  to  be  consistent  with  the  planned 
architecture.  The  impact  of  the  architecture  on  the 
USI  (and  vice  versa)  shall  be  considered. 
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At  the  SDR,  the  contractor  shall  produce  a 
description  of  the  sequence  and  timing  of  user 
actions  and  software  responses  to  illustrate  the 
compliance  of  the  US1  with  the  overall  architecture. 
In  particular,  the  handling  of  anomalous  and  error 
situations  and  the  resultant  movement  of  information 
to  and  from  the  USI  shall  be  discussed.  The  use  of 
previously  developed  software  in  the  design  or 
operation  of  the  USI  shall  be  described. 

The  contractor  shall  provide  information 
sufficiently  detailed  so  that  the  government  can 
determine  that  the  USI  design  and  the  planned 
hardware  and  software  implementations  are  consis¬ 
tent  with  the  planned  architecture.  This  information 
shall  be  delivered  in  the  form  of  briefings  and 
portions  of  the  S/SDD.  [DI-CMAN-80534] 

xjtjc  Security  Engineering 

The  design  of  needed  security  features  shall  be 
accomplished  by  the  contractor  in  such  a  manner  as 
to  preserve  the  architecture  planned  for  the  system. 
The  impact  of  security  features  upon  the  overall 
architecture  and  design  shall  be  presented  as  part  of 
each  design  review  at  a  level  of  detail  determined  by 
the  maturity  of  the  design  effort  at  that  time.  No 
alterations  to  the  security  design  shall  be  considered 
without  a  thorough  determination  of  the  impact  upon 
the  future  of  the  system;  alternatives  tliat  are  in 
concert  with  the  planned  architecture  shall  be  given 
greater  weight  than  permitting  changes  to  the 
architecture.  The  contractor  shall  deliver  to  the 
government  a  System  Security  Architecture  Docu¬ 
ment  [DI-MISC-xxxx]  which  identifies  all  compo¬ 
nents  of  the  system  that  contain  security-relevant 
functions;  this  document  shall  thoroughly  describe 
the  integration  of  security  features  into  the  design  of 
the  hardware  and  software. 


ATTACHMENT  II  —  PROPOSED 
AMENDMENT  OF  DATA  ITEM 
DESCRIPTION  FOR  THE  SYSTEM/ 

SEGMENT  DESIGN  DOCUMENT 

1.  Amendment  to  DI-CMAN-80534  (S/SDD 
DID): 

a.  10.1.1-10.1.5.3.4  No  change. 

b.  10.1.5.4.  System  Architecture.  Replace 
the  current  wording  with  the  following: 

This  paragraph  shall  be  numbered  3.4  and  shall 
be  divided  into  subparagraphs  to  describe  the 
internal  structure  of  the  system  and  the  software 
architecture.  The  system  segments,  HWCIs  and 
CSCIs,  shall  be  identified  and  their  purpose  summa¬ 
rized.  The  system-level  relationships  among  the 
segments,  HWCIs,  and  CSCIs  shall  be  described. 
Paragraph  3.4  shall  also  identify  and  state  the 
purpose  of  each  external  interface  of  the  system.  A 
system  architecture  diagram  may  be  used  to  illustrate 
the  system  top-level  architecture.  There  shall  be 
subparagraphs  that  describe  the  top-level  software 
architecture  structure,  timing,  and  allocation 
attributes.  One  or  more  software  architecture 
diagrams  may  be  used  to  illustrate  the  different 
software  attributes  that  comprise  software 
architecture. 

10.1.5.4.1  Software  Structure.  This  paragraph 
shall  be  numbered  3.4.1  and  shall  describe  the  major 
software  entities  that  will  be  developed  or  integrated 
into  the  system  by  the  software  designers,  the 
mechanisms  for  flow  of  data  among  the  major 
software  entities,  and  the  mechanisms  for  flow  of 
control  among  the  major  software  entities.  Software 
entities  should  be  the  major  software  entities  that 
will  be  recognized  and  manipulated  by  the  system 
developers  as  the  natural  partitions  within  the 
software.  In  this  context,  component  does  not 
specifically  refer  to  Computer  Software  Components 
(CSCs).  Components  may  be  partitioned  by  algorith¬ 
mic  functions,  objects,  and  reusable  components 
such  as  operating  systems  and  database  systems,  or 
by  any  other  scheme  appropriate  to  the  proposer’s 
development  methodology.  The  entities  defining  the 
software  structure  should  reveal  the  underlying 


structure  of  the  software  rather  than  hardware 
allocation  or  administrative  and  management 
controls  that  are  often  used  as  the  criteria  for 
defining  CSCIs. 

This  paragraph  shall  also  describe  the  mecha¬ 
nisms  for  managing  the  flow  of  data  through  the 
components.  It  should  show  the  major  data  paths 
between  and  among  transformation  processes  as  well 
as  to/from  data  storage.  Where  the  flow  of  data  is 
controlled  by  table-driven  design,  the  data  structures 
and  their  rules  for  modifying  data  flows  should  be 
described.  It  should  define  data  structure  and  how 
file  management  and  database  management  struc¬ 
tures  will  be  used. 

This  paragraph  shall  also  describe  the  mecha¬ 
nisms  for  managing  the  flow  of  control  among  the 
components.  It  should  show  the  major  execution 
sequences,  where  execution  sequences  may  be 
asynchronous  or  parallel,  and  how  synchronization  is 
managed.  Where  execution  control  uses  data-driven 
design,  the  mechanisms  for  accessing  the  table  and 
managing  execution  shall  be  described.  It  should 
also  show  how  anomalous  conditions  such  as  error 
handling  and  exception  conditions  that  dynamically 
alter  the  flow  of  execution  are  managed. 

10.1.5.4.2  Timing.  This  paragraph  shall  be 
numbered  3.4.2  and  shall  describe  the  presence  of 
critical  timing  and  throughput  processes.  The 
software  architectural  devices  used  to  manage 
critical  timing  events,  interrupts,  throughput  load 
balancing,  and  data  buffering  shall  be  described. 

10.1.5.4.3  Interconnection  layers,  standards 
and  protocols.  This  paragraph  shall  be  numbered 

3.4.3  and  shall  describe  the  software  architecture 
rules  for  interconnecting  layered  software  entities.  It 
shall  describe  allowable  interconnections  among 
layers,  and  identify  the  use  of  standardized  interface 
protocols  or  bindings  such  as  SQL,  GOSIP,  Motif, 
etc. 

10.1.5.5  Operational  Scenarios.  Replace  the 
current  wording  with  the  following: 
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This  paragraph  shall  be  numbered  3.S  and  shall 
describe  each  operational  scenario  of  the  system.  For 
each  system  state  and  mode,  this  paragraph  shall 
identify  the  hardware  and  software  entities  that 
execute  and  the  manual  operations  to  be  performed. 
A  table  may  be  provided  to  illustrate  the  states  and 
modes  in  which  each  hardware  and  software  entity 
executes  and  each  manual  operation  is  performed.  In 
addition,  this  paragraph  shall  describe  the  general 
flow  of  both  execution  control  and  data  between 
hardware  and  software  entities  while  operating  in  the 
different  states  and  modes.  Flow  diagrams  may  be 
used  to  illustrate  execution  control  and  data  flow  in 
each  state  and  mode. 

10.1.5.6  Software  Architecture  Rationale. 

This  paragraph  shall  be  numbered  3.6  and  shall 
describe  the  selection  criteria  and  constraints  that 
drove  the  choice  of  software  architecture.  It  shall 
include  cross-references  to  requirements  in  the  SSS, 
the  vision  statement,  or  derived  requirements  that 
govern  the  choice  of  software  architecture. 
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ATTACHMENT  III  —  PROPOSED 
AMENDMENT  OF  DATA  ITEM 
DESCRIPTION  FOR  THE  SOFTWARE 
DEVELOPMENT  PLAN 

1.  Amendment  of  DI-MCCR-80030A  (SDP 
DID) 


a.  10.1  — 10.2.5.11  No  change. 

b.  10.2.5.12  Software  Architecture.  This 
paragraph  shall  be  numbered  3.12  and 
shall  describe  the  development  manage¬ 
ment  provisions  for  ensuring  the  software 
architecture  is  preserved  throughout  the 
development  life  cycle.  It  shall  describe 
the  contractor’s  procedures  and  methods 
for  establishing  an  architecture  definition, 
ensuring  software  developers  understand 
the  architecture,  and  ensuring  software 
developers  follow  design  guidelines 

that  enforce  the  preservation  of  the 
architecture. 

c.  10.2.6  —  10.2.6.2  No  change. 

d.  10.2.6.2.  l  Software  Development  Tech¬ 
niques  and  Methodologies.  Replace  the 
current  wording  with  the  following: 

This  subparagraph  shall  be  numbered  4.2.1 
and  shall  identify  and  describe  the  tech¬ 
niques  and  methodologies  the  contractor 
plans  to  use  to  perform: 

a.  Software  Requirements  Analysis 

b.  Software  Architecture  Analysis  and 
Definition 

c.  Preliminary  Design 

d.  Detailed  Design 

e.  Coding  and  Computer  Software  Unit 
Testing 

f.  CSC  Integration  and  Testing 

g.  CSCI  Testing 

e.  10.2.6.2.2  —  10.2.12  No  change. 
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ATTACHMENT  IV  —  INSTRUCTIONS  FOR 
PROPOSAL  PREPARATION 

The  following  material  is  provided  for  insertion 
into  the  IFPP  to  elicit  information  needed  by  the 
government  in  the  area  of  software  architecture. 
These  words  are  general  in  nature  and  must  be 
modified  to  match  the  explicit  needs  of  each 
program  and  to  be  consistent  with  the  remainder  of 
the  IFPPand  the  selection  basis  (see  Section  M). 

The  information  given  below  is  intended  to  supple¬ 
ment  the  information  that  would  conventionally  be 
in  the  IFPP.  It  may  be  convenient  to  merge  the 
following  material  into  the  other  information 
contained  in  the  IFPP.  In  particular,  offerors  should 
not  be  required  to  submit  additional  copies  or  mere 
reformulations  of  information  requested  by  other 
portions  of  the  IFPP.  Offerors  should  also  be 
required  to  provide  an  index  that  would  indicate  the 
location  of  architecture-related  information  through¬ 
out  the  proposal. 

xjc.x  System  Engineering 

Describe  the  overall  architecture  of  the  system 
by  indicating  the  partitioning  of  the  system  into 
major  hardware  and  software  components.  Describe 
systems  with  which  the  contractor  is  familiar  that 
have  similar  characteristics  and/or  are  based  on 
similar  components.  Explain  the  manner  by  which 
information  is  to  be  passed  among  components  and 
the  control  of  execution.  Describe  how  the  architec¬ 
ture  selected  satisfies  the  requirements  in  the  SSS 
and  accommodates  the  vision  statement.  Describe 
the  system  services  that  provide  for  communication 
(both  control  and  data)  among  software  processes 
and  tasks,  hardware  processors,  external  systems  and 
devices,  and  the  USI.  Any  other  information 
requested  in  the  DID  for  the  S/SDD,  or  from  other 
sources,  should  be  presented. 

x-x-x  Software  Engineering 

Describe  the  standards  to  be  followed  in  the 
software  design  and  identify  any  conflicts  with  the 
proposed  architecture  caused  by  use  of  these 
standards.  Identify  the  tools  to  be  used  in  generating 
the  software.  Describe  how  inadvertent  and  deliber¬ 


ate  departures  from  the  proposed  architecture  are 
recognized,  reported,  and/or  prevented.  Identify  any 
software  components  previously  developed  (COTS 
or  other  NDI)  and  how  they  may  have  to  be  adapted 
to  conform  to  the  proposed  software  architecture. 

Describe  how  and  when  the  execution  sequence 
is  determined;  include  the  handling  of  interrupts, 
errors,  oul-of-normal  situations,  and  response  to 
timing  constraints.  Discuss  how  the  execution 
sequence  can  be  redefined. 

xjut  Database  Engineering 

Describe  the  proposed  database  architecture 
with  particular  emphasis  on  Uiose  attributes  that 
contribute  to  or  detract  from  the  proposed  software 
architecture.  Identify  any  tools  to  be  employed  in 
developing  the  database  design.  Identify  any 
available  data  management  packages  (COTS  or 
other  NDI)  and  whether  the  use  of  these  packages 
affects  the  proposed  software  architecture. 

XJC.X  User  Interface  Engineering 

Describe  the  proposed  USI  and  associated 
methods  for  data  display,  data  entry,  sequence 
control,  and  user  assistance  within  the  architectural 
framework  proposed  for  the  system.  Identify  any 
rapid  prototyping  tools  that  will  be  used  to  support 
the  User  Interface  Demonstration  and  how  these 
tools  will  be  used  in  a  manner  attuned  to  the  pro¬ 
posed  architecture.  Describe  how  any  COTS/or  other 
NDI  software  will  provide  the  USI  while  preserving 
the  proposed  architecture.  Describe  how  the  results 
of  USI  demonstration  activities  will  be  incorporated 
into  the  design,  development,  and  test  of  the  system. 

x.x.x  Security  Engineering 

Describe  the  proposed  security  design  and  the 
allocation  of  functions  to  hardware  and  software 
components. 

x.x.x  Modeling  and  Prototyping 

Describe  how  the  architectural  assumptions  and 
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conditions  are  to  be  imposed  on  the  system  models 
used.  Indicate  to  what  extent  the  performance 
models  will  be  calibrated  against  other  systems  using 
the  same  (or  similar)  architectures.  Describe  how 
(and  when  during  the  design  activities)  the  architec¬ 
tural  model  will  be  subjected  to  execution  and  to 
validation. 
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GLOSSARY 


CDR 

Critical  Design  Review 

CDRL 

Contract  Data  Requirements  List 

CSC 

Computer  Software  Components 

CSCI 

Computer  Software  Configuration  Item 

COTS 

Commercial-Off-the-Shclf 

DI 

Data  Item 

DID 

Data  Item  Description 

ECP 

Engineering  Change  Proposal 

GOSIP 

Government  Open  Systems 
Interconnection  Profile 

HWCI 

Hardware  Configuration  Item 

IFPP 

Instructions  for  Proposal  Preparation 

NDI 

Non-Developmental  Item 

PDR 

Preliminary  Design  Review 

POSIX 

Portable  Operating  System  Interface  for 
Computer  Environments 

RFP 

Request  for  Proposal 

SDD 

Software  Design  Document 

SDP 

Software  Development  Plan 

SDR 

System  Design  Review 

SRR 

System  Requirements  Review 

S/SDD 

System/Segment  Design  Document 

sss 

System  Segment  Specification 

TIM 

Technical  Interchange  Meeting 

TRR 

Test  Readiness  Rev  w 

USI 

User-System  Interface 
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